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DESCRIPTION 

Field of the invention 

The present invention relates to a method for downloading a multimedia content, 
for instance a live event, to a client device. The invention also relates to a network, a 
system, a slicer, a server, and a client device specifically designed to implement such a 
downloading method. 

The invention has interesting applications for the transmission of live multimedia 
contents (like five events or broadcasted TV programs) to client devices via the Internet 
It also applies to the transmission of video from one mobile device to one or more peer 
devices via the Internet. 



Background of the invention 

The document "An RTP to HTTP Video Gateway" by Mathias Johanson, 
WWW10, May 1-5 2001, Hong-Kong (ACM, 1-581 13-348-0/01/0005) relates to the 
transmission of videoconferencing content through the Internet. 

Typically when five multimedia contents are transmitted through an IP network, 
the transport protocol that is used is RTP (Real time Transport Protocol) over UDP (User 
Datagram Protocol). RTP is defined in the RFC1 889 published by me IETF (Internet 
Engineering Task Force). UDP is a connection less transport protocol defined in the 
RFC0768 of the IETF. 

20 As stated in the above-mentioned document, a main problem when using 

RTP/UDP is that generally firewalls don't allow UDP traffic to pass through and that in 
many cases Ifiey employ techniques like Network Address Translation (sometimes 
referred to as NAT) that complicate end-to-end real time communication. As a 
consequence, the vast majority of Internet users are not able to receive live multimedia 
25 contents like videoconferencing content. 

The solution proposed in this document is specifically designed for 
videoconferencing applications. It consists in encoding the video content into a sequence 
of JPEG images and in describing the sequence of JPEG images as a MIME 
multipart/mixed message where each part of the message is of the image/JPEG type 
(MIME stands for Multipurpose Internet Mail Extension; it describes a format for 
electronic messages). When the client browser is recognized as not capable of displaying 
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MIME multipart/mixed content, a specific java applet is downloaded to the client device 
to ensure correct display of the sequence of JPEG images. 

The solution proposed in this document may be satisfactory for certain types of 
applications, in particular for web-camera applications. However it is not adapted to the 
5 transmission of large multimedia contents like live events or movies for the reasons 
stated below: 

- In the proposed solution, the video is encoded as a sequence of JPEG images. Each 
image is encoded independently so that the temporal redundancy between images is not 
exploited. Therefore the compression ratio is low. It is definitively too low to allow for 

10 the transmission of large video contents via low bit rate connections like Internet 
connections and/or mobile networks. 

- The proposed solution doesn't provide an appropriate solution for handling the audio 
part of the video content In particular synchronizing the images with the audio is not 
straightforward. 

1 5 Another drawback of the proposed solution is that it is based on the MIME 

multipart message format which, in practice, is not supported by most of the client 
browsers. 

One of the objects of the invention is to propose an efficient solution for 
transmitting live multimedia contents in real time from a server to a client device. 

20 

Summary of the invention 

This is achieved with a network a claimed in claim 1, a system as claimed in 
claim 2, a slicer as claimed in claim 3, a server as claimed in claims 4 to 7, a client 
device as claimed in claims 8 and 9, and a downloading method as claimed in claim 10. 
25 A network according to the invention comprises: 

- a source for acquiring a multimedia content, 

- an encoder for encoding said multimedia content, 

- a slicer for slicing said encoded multimedia content in at least one set of slicing 
positions so as to generate at least one set of slices where each slice can be decoded 

30 independently from the others, and for providing at least one set of files, each file 
containing a slice of said encoded multimedia content, 

- a distribution network, 

- an access provider for providing a client device with an access to said distribution 
network, 
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- a server linked to said distribution network and having access to said set(s) of files for 
downloading at least one of said files to said client device via said distribution network 
upon reception of an initial request from said client device, said request being directed to 
said encoded multimedia content. 

5 The invention proposes to transform a multimedia content (for instance a 

broadcasted TV program, a broadcasted five event, or a personal video capture with a 
mobile device) into a file-based content. More specifically, the proposed solution 
consists in slicing an encoded content into a plurality of slices where each slice 
comprises a given amount of time of the content and can be decoded independently from 

10 the other slices. Each slice is stored in a file that can downloaded as soon as it is ready at 
the server side and can be played as soon as it is received at the client side. 

According to the invention the file-based content is transmitted from the server to 
Ihe client device via a point-to-point connection. On IP networks, point-to-point 
connections are usually ruled by Ihe HTTP protocol (Hyper Text Transfer Protocol, 

15 defined in the RFC2616 of the IETF). The HTTP protocol is the basis for the World 
Wide Web and therefore has the great advantage of being accepted by all firewalls and 
Networks Address Translators. This means that the transmitted content will be 
accessible for any client device having access to the World Wide Web without 
restriction. 

20 The invention proposes to generate one or more set of files for the same 

multimedia content When several sets of files are generated, the slicing positions vary 
from one set to another (the files are starting at different positions in time in each set). 
When a client sends an initial request, he receives either the previous file -which means 
he will receive out of date information- or he has to wait for the next file to be ready. In 

25 both cases, using several sets of files allows reducing the inconvenience for the user. The 
number of sets is a compromise between the inconvenience experienced by the client 
and the storage unit space needed to store the files. 

According to the invention it is possible to download one file only, upon 
reception of an initial request by a client device. This is advantageous for certain 

30 applications, for instance to allow clients to get a quick outlook of the results during 
championships. 

In a first embodiment, the server has: 

- means for sending a document to said client device upon reception of said initial 
request, said document causing said client device to repetitively send a fetching request 
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designating said encoded multimedia content, 

- means for selecting which file is to be downloaded amongst said set(s) of files, upon 
reception of said fetching requests from said client device, 

- means for downloading the selected file. 

5 The files can be either fetched one by one by the client device or sent one by one 

by the server upon reception of an initial request. In practice, it is not certain that all 
client browsers will support receiving several files in response to one single request 
Therefore it will usually be preferred that the client device fetches the files one by one 
(i.e. sends a fetching request for each file to be downloaded). 
10 The client device can be designed specifically so as to send automatically the 

fetching request at the appropriate time. But it is usually preferred to use standard client 
devices. Therefore it is advantageous to send a document from the server to the client 
device, said document causing the client device to repetitively send a fetching request. 
Advantageously, said document comprises an instruction for the client device to 
15 send a subsequent fetching request a certain amount of time before the end of the 

playback of the previous file. In such a way, it is made sure that the next file will reach 
the client device early enough, and that the client will not experience any gap in the 
playback process. 

In a second alternative embodiment, the server has: 
20 - means for sending a document to said client device upon reception of said initial 

request directed to an encoded multimedia content, said document comprising a resource 
identifier designating said encoded multimedia content and specific to said client device, 
said document causing said client device to repetitively send a fetching request 
containing said resource identifier, 
25 - means, activated upon reception of a first fetching request, for: 

selecting a first file amongst said set(s) of files, downloading the selected file, and 
keeping a record of said resource identifier together with an indication of which file was 
downloaded, 

- means, activated upon reception of subsequent fetching requests, for: 
30 checking said record so as to select the file that follows the one that was previously 
downloaded, downloading the selected file, and updating said record. 

HTTP is a stateless protocol and therefore HTTP requests issued by the same 
client device are normally processed independently one from the other. This second 
embodiment is advantageously used when several sets of files are generated for the same 
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multimedia content so as to allow the server to keep track of each client As the 
knows which file is to be sent next for each client, smooth playback of the content 
be achieved 



server 
can 



Brief description of the figures 

These and other aspects of the invention are further described by reference to the 
following drawings: 

- figure 1 is a schematic representation of a first example of network according to the 
invention, 

- figure 2 is a schematic representation of a plurality of sets of files generated by a sheer 
according to the invention, 

- figure 3 is a schematic representation of two overlapping files, 

- figure 4 is schematic representation of three sets of files, 

- figure 5 is a block diagram of a method according to the invention for downloading a 
1 5 five multimedia content, 

- figures 6 and 7 are schematic representations of other examples of a network according 
to the invention. 



Description of preferred em bodiment 

Figure 1 is a schematic representation of a network according to the invention. 
The network of figure 1 comprises: 

- a source 1 for acquiring a multimedia content; 

- a broadcaster 2 for broadcasting said multimedia content; 

- a receiver 3 for receiving a broadcasted multimedia content; 

- a system 4 comprising an encoder 5 for encoding a received multimedia content, and a 
slicer 6 for slicing an encoded multimedia content in at least one set of slicing positions 
so as generate at least one set of shoes where each slice can be decoded independently 
from the others, and for providing at least one set of files, each file containing a slice of 
said encoded multimedia content, 

30 - a server 8 having access to said files, 

- a distribution network 10, the server 8 being linked to the distribution network 10, 

- an access provider 12 for providing a client device 14 with an access to the distribution 
network 10. 



The client device 14 has (amongst other means not represented in figure 
1) a communication unit 15 for transmission/reception to/from the access provider 12, a 
player 16 for playing an encoded multimedia content, and a display 17 for displaying a 
multimedia content. The client device 14 can be either a mobile device (like a mobile 
5 phone) in which case the communication unit 1 5 is a radio communication unit, or a 
wired device (like a PC) in which case the communication unit 1 5 is a wired 
communication unit. The distribution network 10 is typically the Internet network. 

For instance the broadcaster 2 is a satellite broadcasting network and the receiver 
3 is a satellite receiver. This is not restrictive: any other broadcasting means could be 
10 used instead of satellite broadcasting means. The broadcasted multimedia content can be 
any multimedia content that is transmitted and can be received by a number of receivers 
including the receiver 3. For instance the broadcasted multimedia content can be a 
television program, a pre-recorded event/program, a live event. . . 

The encoder 5 is responsible for encoding the received multimedia content. For 
15 instance the encoder 5 is compliant with one of the MPEG standards, or with H263. 

The encoder 5 and the slicer 6 are either implemented in a single device or in two 
separated devices. In both cases, what is transmitted from the encoder 5 to the slicer 6 is 
an encoded video stream. Advantageously this encoded video stream is transmitted from 
the encoder 5 to the slicer 6 over IP by using the RIP protocol. This is not restrictive. By 
20 way of example, the transport layer of the MPEG-2 standard, known as MPEG-2 TS, 
could be used as well. 

In practice, the files generated by the slicer 6 are stored in a storage unit 20 to 
which the server 8 has access. The storage unit 20 is shared by the slicer 6 and the server 
8. The storage unit 20 can be part of the server equipment or can be located remotely. 
25 The function of the slicer 6 is to slice the encoded content generated by the 

encoder 5 into a plurality of slices where each slice comprises a given amount of time of 
the encoded multimedia content and can be decoded independently from the other slices. 
In practice, any encoded multimedia content generated by a multimedia encoder 
comprises so-called Random Access Points (RAP). In order to produce slices that can be 
30 decoded independently one from the others, the slicer 6 slices the encoded multimedia 
content in such a way that each slice starts with a Random Access Point. For instance, 
when the encoder is compliant with the MPEG-2 or MPEG-4 standard, the random 
access points are the I-frames of the MPEG-encoded multimedia content, and the slicing 
positions are chosen in such a way that the first frame of each slice is an I-frame. 
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Advantageously the size of the slices is adjustable. It may be identical for all 
slices or it may vary from one slice to another (for instance the size of the slices may 
increase along time). The best efficiency is obtained with files that are relatively long 
because the more files to be transported the more overhead due to file headers. 
5 Each slice generated by the sheer 6 is stored as a file in the storage unit 20. The 

storage unit 20 has to be "cleaned" on a regular basis to ensure that there is available 
room for storing the newly generated files. A way of cleaning the storage unit is to re- 
use file names on a regular basis. An alternative way is to use different file names for 
each file, and to delete the aging files on a regular basis. 

10 According to the invention the sheer 6 generates either one set of files or a 

plurality of sets of files for the same multimedia content. When the sheer 6 generates a 
plurality of sets of files, aplurality of sets of slicing positions are used, each set of 
slicing positions being shifted in time compared with the other sets of slicing positions. 
Figure 2 is an illustration of aplurality of sets of files Si, Sa, S N generated by the 

15 sheer 6. Each set of files Si comprises K files Fy (i=l, ...,N; j=l,...,K). A set of slicing 
positions {T M , ...,Tyj} is associated to each set of files Si. As illustrated in figure 2, the 
slicing positions T i+1 j are shifted in time compared to the slicing positions Ty (the axis t 
is the time axis). In other words, the files F Wj and Fy are overlapping (they comprise 
identical encoded data). In figure 3, the overlap between the files F i+1J and Fy is 

20 indicated by an arrow O i+ i. 

As will be apparent in the description below generating a plurality of sets of files 
is advantageous because it allows reducing the delay experienced by the client when 
he/she sends a request for a multimedia content. 

The server 8 is linked to the distribution network 10. The client device 14 has 
25 access to the distribution network 10 via the access provider 12. Typically, the client 
device 14 can load through the distribution network 10 a page containing at least one 
link to one encoded multimedia content that the server 8 offers to download. When a 
user clicks on said link, an initial request R<, directed to said encoded multimedia content 
is sent automatically to the server 8. There are several possible ways for the server 8 to 
30 handle the initial request Ro. 

In a first embodiment, the server 8 downloads a single file in response to the 
client request This implementation can be used for specific applications, for instance for 
applications offering the client to pick-up information regarding a live event. It can also 
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be used with a player 16 specifically designed to cause the client device 14 to send the 
initial request Ro repetitively. 

In a second embodiment, the server 8 downloads the files one by one as soon as 
they are ready at the server side. This embodiment has the advantage of being easy to 
5 implement. But there is a risk that certain client browsers will not support receiving 
several files in response to one single request 

In a third embodiment (usually preferred), upon reception of the initial request 
Ro, the server 8 sends a document to the client device 14. This document causes the 
client device 14 to repetitively send a fetching request designating the encoded 
10 multimedia content 

By way of example, the document sent by the server 8 can be a page comprising 
an automatic refresh command. An example of such a page is given below: 
<html> 
<head> 

15 <META meta http-equiv="Refresh" contend" 134" ; 
url= f http://www.yow^^ " 
</head> 

<embed src="live2download.mp4" width="240" height" 240 ff > 
<embed> 
20 </html> 

Such a page causes the client browser to reload the file "live2download.mp4" 
every 134 seconds (which is the duration of a file in this example). 

Alternatively, the document sent by the server 8 can be a standard description of 
the multimedia content, said standard description being intended to be processed by the 
25 player 1 6 in a standard way. For instance such a description can be a SMIL description 
(SMIL is a W3C standard defining XML-based audio/video scene descriptions). An 
example of such a SMIL description is given below: 
<smil> 
<head> 
30 <layoufc> 

<*oot-layoutwidth="240" height="240" background-color="white"/> 
<regkm regionName="im" leff=" 0" top="0" width-"240" height="240"/> 
</layoute> 
</head> 
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<body> 

<seq repeatCount = "indefinite" > 

<video id="vid" src^"live2download.mp4" region="im" /> 
<7seq> 
5 <7body> 
</smil> 

The effect of this SMIL document is to cause the player 16 to play the file 
"Hve2download.mp4" repetitively. As a result the client device will repetitively send 
fetching requests directed to the file "tive2download.mp4". 

10 Advantageously, the SMIL document sent by the server 8 comprises a command 

indicating that the files have to be fetched some time in advance (that is some time 
before the end of the playback of the previous file). This ensures that the next file will 
arrive on time at the client device 14 so that the client will not experience a gap in the 
rendering of the multimedia content. An example of a SMIL description having such a 

15 command is given below: 
<smil> 
<head> 
<Iayout> 

<root-layoutwidth="240" heigh<="240" background-color="white f 7> 
20 <region regionName="im H leffc="0" top=" 0" width="240" height="240"/> 
</layout> 
</head> 
<body> 

<seq repeatCount = "indefinite" > 
25 <video id="vid" src="live2downloadl.mp4" region="im" clipBegin « "0s" dur 
« "25s" /> 
<par> 

<prefetch src?="live2download2.mp4" mediaTime ="5s" /> 
<video id=="vid" src="live2downloadLmp4" region="im" clipBegin = "25s" /> 
30 </par> 

<video id="vid" src-"live2download2.mp4" region="im" clipBegin = "0s" dur 

= "25s" /> 

<par> 

<prefetch src= s "live2downloadl.mp4" mediaTime ="5s" /> 
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<video id="vid" src= ff live2download2.mp4" region="im" clipBegin = "25s" /> 

<Vpar> 

<seq> 

</body> 

</smil> 

This document is written for slices containing 30s of content It causes the player 
to execute the following operations in sequence: 

a) playing the first 25s of a first source (live2downloadl .mp4); 

b) playing the last 5s of the first source and in parallel fetching the first 5s of a second 
source (Hve2download2.mp4); 

c) playing the first 25s of the second source (which can be done without delay since the 
first 5s have been pre-fetched). 

Using two different sources is an implementation trick. The server 8 must be designed to 
recognize that the first and the second sources correspond to the same encoded 
multimedia content 

In the three embodiments described above, the server has to select a file to 
download upon reception of the initial request Ro or upon reception of the fetching 
requests. The server 8 can either select the most recent file or the first file to get ready. 
The consequence of selecting the most recent file is that the client will receive out-of- 
date data. The consequence of selecting the first file to get ready is that the client will 
have to wait a certain time before getting a response. In both case the inconvenience for 
the client is reduced when several sets of files are used. This is illustrated in figure 4. 

In figure 4, three sets of files Si, S2 and S3 are represented. An arrow A indicates 
the reception of a request by the server 8. 

When the only set to be generated by the slicer 6 is the first set Si, the server 8 
will either download the file Fi,i (the most recent file) or the file Fi >2 (the next file to get 
ready). If the server 8 downloads the file Fi.i, then the data received by the client will be 
late by a time equal to ai,!. If the server downloads the file Fi >2 , then the client will 
experience a delay equal to bi^ before receiving the data. 

When the three sets Si, S 2 and S 3 are generated by the slicer 6, the server 8 will 
either download the file F 2 ,i (the most recent file) or the file F 3 , 2 (the next file to get 
ready). If the server 8 downloads the file F 2 ,i, then the data received by the client will be 
late by a time equal to a 2 ,i. If the server downloads the file F 3>2 , then the client will 
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experience a delay equal to before receiving the data. It can be seen that a M >a 2 ,i and 
bi^>b3,2. 

The transmissions over the distribution network 10 are ruled by the HTTP 
protocol. 

HTTP is a stateless protocol and therefore HTTP requests issued by the same client 
device are normally processed independently one from the other. As a result, in the third 
embodiment of the invention, there is a risk that the playback of the content cannot be 
achieved smoothly (some parts of the content may be received several times, or some 
parts of the content may be missing). A fourth embodiment of the invention will now be 
described that solves this problem. 

In the fourth embodiment of the invention, the document sent by the server 8 in 
response to the initial request Ro comprises a resource identifier designating the encoded 
multimedia content asked by the client. This resource identifier is specific to the client 
device 14. The document sent by the server 8 causes the client device 14 to repetitively 
send a fetching request containing this resource identifier. Upon reception of the first 
fetching request, the server 8 selects the file to be downloaded as described above (it 
selects either the most recent file or the next file to get ready). The server 8 downloads 
the selected file and keeps a record of which file was downloaded (or alternatively which 
file is next to be downloaded). Upon reception of subsequent fetching requests 
containing the same resource identifier, the server 8 checks the record to select the file to 
download, downloads the selected file and updates the record. 

In this way, each client device 14 will receive a sequence of files that is complete 
and correctly ordered (all the received files are consecutive files belonging to the same 
set of files). 

By way of example the resource identifier comprised in the document sent by the 
server 8 can be a "nonce" as defined in the RFC1510 of the IETF (a nonce is a number 
that is used only once). An example of a SMIL document comprising such a resource 
identifier is given below: 
<smil> 
<head> 
<layout> 

<root-layoutwidth="240 fl height="240" background-color="white"/> 
<region regionName^"im" lefl="0" top="0" width="240" heightr= fl 240"/> 
</Iayoufc> 
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<head> 
<body> 

<seq repeatCount = "indefinite" > 

<video id= ff vid" src="cnnl42299293873635534291919.mp4 ff region="im" /> 

</seq> 

</body> 

<7smil> 

Here the resource identifier is cnnl42299293873635534291919. The client device 14 
will repetitively send fetching requests for the file 

cnnl42299293873635534291919.mp4. And the server 8 will keep track of which file 
was downloaded (or is to be downloaded) for the resource identifier 
cnnl42299293873635534291919. 

The steps that have been discussed above are summarized in Figure 5. According 
to figure 5, a method according to the invention for downloading a multimedia content 
M comprises: 

- a step XI of producing an encoded a multimedia content E(M), 

- a step X2 of slicing the encoded multimedia content E(M) in at least one set of slicing 
positions so as to generate at least one set of slices, where each slice can be decoded 
independently from the other, and providing at least one set of files Si, S 2 , . . S N , each 
file Fy (i=l,. . N; j=l,...,K) containing a slice of said encoded multimedia content, and 

- a step X3 of downloading at least one of said files to the client device 14 via the 
distribution network 10 upon reception of an initial request Ro directed to the encoded 
multimedia content E(M) from the client device 14. 

These steps are implemented by way of specific hardware and/or software 
comprised in one or several devices. For instance in figure 1, step XI is implemented by 
the encoder 5, step X2 is implemented by the slicer 6, and step X3 is implemented by the 
server 8. 

Two other examples of a network according to the invention will now be 
described by reference to figures 6 and 7. 

The network of figure 6 comprises a first client device 50, a distribution network 
52, a second client device 54, and at least one access provider 56 for providing the first 
and the second client devices 50 and 54 with an access to the distribution network 52. 
The second client device 54 is similar to the client device 14 described by reference to 
figure 1 . Typically the distribution network 52 is the Internet network. 
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The first client device 50 comprises: 

- a source 60 for acquiring a multimedia content, 

- an encoder 62 for encoding an acquired multimedia content, 

- a slicer 64 for slicing an encoded multimedia content in at least one set of slicing 
positions so as generate at least one set of slices where each slice can be decoded 
independently from the others, and for providing at least one set of files, each file 
containing a slice of said encoded multimedia content, 

- a server 66 having access to said files, 

- a communication unit 68 for transmission/reception to/from the access provider 56. 

Typically the first client device is a mobile phone, which means that the 
communication unit 68 is a radio communication unit 

The functionalities of the source 60, the encoder 62, the slicer 64 and the server 
66 are identical to the functionalities of the source 1, the encoder 5, the slicer 6 and the 
server 8 described above by reference to figures 1 to 4. 

Figure 7 gives a schematic representation of an alternative solution where the 
server 66 is located in the distribution network 52 instead of being located in the first 
client device 50. In this embodiment, the first client device 50 will upload the files 
generated by the slicer 64 to the server 66, and the server 66 will in turn download at 
least one the files to the second client device 54. 

Typically the first client 50 sends a link toward an encoded multimedia content 
(for instance a video that has just been captured by the first client device 50) to the 
second client device 54, for instance via SMS (Short Message Service). When the 
second client clicks on the link contained in the SMS, an initial request directed to the 
encoded multimedia content is sent to the first client device 50. Upon reception of this 
initial request, the first client device 50 operates as described above with reference to 
figures 1 to 4. 

With respect to the described network, server, system, slicer, client device, and 
downloading method, modifications or improvements may be proposed without 
departing from the scope of the invention. The invention is thus not limited to the 
examples provided. 

In particular the "progressive downloading" concept disclosed in the European 
patent application n° 03290453.4 filed on May 07, 2003 by Koninklijke Philips 
Electronics N.V. can be combined with present invention. When a file generated by the 
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slicer 6 is progressively downloaded, the player 16 doesn't need to wait until the file is 
completely downloaded to start playing the file. 

The use of the verb "comprise" in the description and in the claims does not 
exclude the presence of other elements than those listed in the description and in the 
claims. 
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CLAIMS 

1 . A network comprising at least: 

- a source (1) for acquiring a multimedia content, 

- an encoder (5) encoding said multimedia content, 

- a slicer (6) for slicing said encoded multimedia content in at least one set of slicing 
5 positions so as generate at least one set of slices where each slice can be decoded 

independently from the others, and for providing at least one set of files, each file 
containing a slice of said encoded multimedia content, 

- a distribution network (10), 

- an access provider (12) for providing a client device (14) with an access to said 
10 distribution network, 

- a server (8) linked to said distribution network and having access to said set(s) of files 
for downloading at least one of said files to said client device via said distribution 
network upon reception of an initial request from said client device, said request being 
directed to said encoded multimedia content. 

15 

2. A system (4) comprising: 

- an encoder (5) for encoding a multimedia content, thereby generating an encoded 
multimedia content, 

■ a slicer (6) for slicing said encoded multimedia content in at least one set of slicing 
20 positions thereby generating at least one set of slices where each slice can be decoded 
independently from the other, and for providing at least one set of files, each file 
containing a slice of said encoded multimedia content 

3. A slicer (6) for slicing an encoded multimedia content in at least one set of slicing 
25 positions thereby generating at least one set of slices where each slice can be decoded 

independently from the other, and for providing at least one set of files, each file 
containing a slice of said encoded multimedia content. 

4. A server (8) having access to at least one set of files (Si) generated by slicing an 

30 encoded multimedia content in at least one set of slicing positions ({T u , . . ..Tyc}) so as 
to form slices that can be decoded independently one from the other, each file (Fy) 
containing a slice of said encoded multimedia content, said server having means for 
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downloading to a client device (14) at least one of said files upon reception of a request 
directed to said encoded multimedia content from said client device. 

5. A server as claimed in claim 4, wherein said downloading means comprise: 

- means for sending a document to said client device upon reception of said request, said 
document causing said client device to repetitively send a fetching request designating 
said encoded multimedia content, 

- means for selecting which file is to be downloaded amongst said set(s) of files, upon 
reception of said fetching requests from said client device, 

- means for downloading the selected file. 

6. A server as claimed in claim 4, wherein said downloading means comprise: 

- means for sending a document to said client device upon reception of said initial 
request, said document comprising a resource identifier designating said encoded 
multimedia content and specific to said client device, said document causing said client 
device to repetitively send a fetching request containing said resource identifier, 

- means, activated upon reception of a first fetching request, for: 

selecting a first file amongst the set(s) of files generated from said encoded multimedia 
content, downloading the selected file, and keeping a record of said resource identifier 
together with an indication of which file was downloaded, 

- means, activated upon reception of other subsequent fetching requests, for: 
checking said record so as to select 1he file that follows the one that was previously 
downloaded, downloading the selected file, and updating said record. 

7. A sever as claimed in one of claims 5 or 6, wherein said document comprises an 
instruction for the client device to send a subsequent fetching request before the end of 
the playback of the file that was downloaded in response to the previous fetching 
request. 

) 8. A client device having: 

- means for connecting to a server, said server having access to at least one set of files 
generated by slicing an encoded multimedia content in at least one set of slicing 
positions so as to form slices that can be decoded independently one from the other, each 
file containing a slice of said encoded multimedia content, said server offering to 
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download at least one of said files, 

- means for sending to said server a request directed to said encoded multimedia content, 

- means for receiving one of said files, 

- means for playing the received file, 

5 - means for sending at least one subsequent request directed to the same encoded 
multimedia content to said server. 

9. A client device as claimed in claim 8, further comprising means for sending said 
subsequent request before the end of the playback of the received file. 

10 

10. A method for downloading an encoded multimedia content to a client device, said 
method comprising the steps of: 

- encoding a multimedia content, 

- slicing said encoded multimedia content in at least one set of slicing positions so as 
15 generate at least one set of slices, where each slice can be decoded independently from 

the other, and providing at least one set of files, each file containing a slice of said 
encoded multimedia content, and 

- downloading at least one of said files to said client device via a distribution network 
upon reception of an initial request directed to said encoded multimedia content from 

20 said client device. 
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ABSTRACT 

METHOD FOR DOWNLOADING A BROADCASTED MULTIMEDIA CONTENT 
OVER A DISTRIBUTION NETWORK 

The invention proposes to transfonn a broadcasted multimedia content (for 
instance a broadcasted TV program or a live event) into a file-based content. More 
specifically, it consists in slicing an encoded content into a plurality of slices where each 
slice comprises a given amount of time of the content and can be decoded independently 

5 from the other slices. Each slice is stored in a file that can downloaded as soon as it is 
ready at the server side and can be played as soon as it is received at the client side. 

The transmission between the server and the client device is ruled by the HTTP 
protocol that is accepted by all firewalls and NAT. The consequence is that the 
transmitted content is accessible for any client device that has access to the Web without 

10 restriction 

Application: downloading a broadcasted content via the internet. 
Reference: figure 1 







1 F1,3 ' 






A 








A 







J 1 



T1.1 



T1.2 



T1.3 



T1,K 



T2.1 



T2.2 



T2.3 



v 82 



T2.K 



t 

TN.1 



T 

TN.2 



Sn 
\4r 



TN.3 



t 
TN.K 





f/IB:*:004/uu2141 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

CTlines OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




BLACK BORDERS 



□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 



□ FADED TEXT OR DRAWING 



□^BLURRED OR ILLEGIBLE TEXT OR DRAWING 



